graph, store: Reject grafts below the base's earliest block#6610
graph, store: Reject grafts below the base's earliest block#6610incrypto32 wants to merge 1 commit into
Conversation
Mirrors the guard added for `graphman copy` in #6384. Without this, grafting at a block below `base.earliest_block_number` silently produces a destination missing all pre-graft mutable entity versions, and (when the base has dynamic data sources) handlers fail with `unexpected null in handler` because `data_sources$` registrations survive pruning while the entities they reference do not.
|
@incrypto32 Why it should reject? Should not subgraph that uses graft follow graft structure and data and therefore just copy graft data and start from the latest graft block? |
|
@0x19dG87 My reasoning was that If Also there is implications for POI: two indexers grafting the same deployment would diverge depending on whether they grafted before or after the base was pruned. The one with the full copy reads real pre-graft state into handlers; the one with the empty copy reads null and writes different entities based on how mappings handle it. Happy to discuss this further if there's uncertainities. Yet to be discussed internally and waiting for a review too from the team. |
2 participants
Graft::validatechecks that the graft block is belowbase.latest_block, above the reorg threshold, and that the base is healthy. It does not check that the graft block is at or abovebase.earliest_block_number.When the base has been pruned past the graft block (or its start block is above it), the copy step silently leaves the destination missing all pre-graft mutable entity versions. Dynamic data source registrations in
data_sources$survive (they are never pruned), so the destination keeps listening to factory-created contracts whose backing entities are gone, producingunexpected null in handlererrors on every event.This adds the missing check, mirroring the equivalent guard added for
graphman copyin #6384.Closes #6581
Closes #6607